No reason for this class to be a part of the NextSessionTimes class, we may end up using it again if we find an endpoint that returns raceweekcars.

Also, we have one or two more, similar Car classes, is there potential for code reuse there? I know i have seen some type of car with an id and a max dry tire sets and so on before, so lets make sure we aren't repeating code just in case.

@XanderRiga Isn't this nested class in line with how we have the other classes setup?

The cases where we did that we were extending another Car and it was a type of car that we would never see anywhere else because they sent different data. I am not super sure that is the case here since they specifically refer to it as raceWeekCars, which to me implies this is a specific type of car that is a race week car, which I believe could be reused.

That being said, if we want to keep it as a class inside the other class it's fine, but we should at least be doing the extending of the base car and only adding the specific fields that don't exist in the base class here.

The race_week_cars is an attribute of NextSessionTimes and RaceGuide.Schedule.Race so I agree that it doesn't make sense to subclass with NextSessionTimes. Also RaceWeekCars is a bit ambiguous since whilst it does list the car id for that session, it's more about some session specific attributes for those cars, which aren't really logical attributes of any other Car classes.

So logically it might sit better as a subclass of Race, but that makes it difficult to access from NextSessionTimes. Leaving it as a standalone class feels like the best place to define it and make it accessible to every object that needs access.